3
תגובות
IoC - השיטות SL ו-DI
פתח
משהה
,
אז ככה, התחלתי ללמוד על הנושאים האלה והבנתי את זה :
IOC - היפוך שליטה, שימוש באינטרפייסים ובמחלקות אבסטרקטיות עבור המחלקות והפרדת המחלקת לפי פעולות. זאת אומרת שכל מחלקה, כל מודול, יבצע פעולה מסויימת ולמנוע כמה שניתן תלות בין המודולים, שכל מודול יעבוד בנפרד.
עכשיו יש כמה דרכים לממש את הIOC הזה , תבנית הFactory ועוד כמה.
אחת מהדרכים זה SL:
Service Locator - במקום לקרוא למחלקה כרגיל
אז קוראים לה דרך הSL והוא בודק האם קראנו בעבר למחלקה ואם כן - הוא פשוט יחזיר לנו את האינסטנס של המחלקה , ואם לא אז הוא ייצור אחד בעצמו
לדוגמה:
או משהו בסגנון
צדקתי במה שאמרתי עד עכשיו ? הבנתי טוב?
ואפשר הסבר מהזה הזרקת תלויות, DI? קראתי על זה הרבה באנגלית ואפילו בעברית איזה מאמר וחצי אבל לא ממש הבנתי עד הסוף איך מממשים את זה ואיך זה עובד.
IOC - היפוך שליטה, שימוש באינטרפייסים ובמחלקות אבסטרקטיות עבור המחלקות והפרדת המחלקת לפי פעולות. זאת אומרת שכל מחלקה, כל מודול, יבצע פעולה מסויימת ולמנוע כמה שניתן תלות בין המודולים, שכל מודול יעבוד בנפרד.
עכשיו יש כמה דרכים לממש את הIOC הזה , תבנית הFactory ועוד כמה.
אחת מהדרכים זה SL:
Service Locator - במקום לקרוא למחלקה כרגיל
$object = new Class;
אז קוראים לה דרך הSL והוא בודק האם קראנו בעבר למחלקה ואם כן - הוא פשוט יחזיר לנו את האינסטנס של המחלקה , ואם לא אז הוא ייצור אחד בעצמו
לדוגמה:
$cookie = $sl->get(Cookie)
או משהו בסגנון
צדקתי במה שאמרתי עד עכשיו ? הבנתי טוב?
ואפשר הסבר מהזה הזרקת תלויות, DI? קראתי על זה הרבה באנגלית ואפילו בעברית איזה מאמר וחצי אבל לא ממש הבנתי עד הסוף איך מממשים את זה ואיך זה עובד.
3 תשובות
ענה
"איך מממשים ואיך זה עובד" זה כבר תלוי באיך אתה כותב את המחלקה.
IoC היא תבנית עיצוב,
מתוך ויוקי:
בהנדסת תוכנה, תבנית עיצוב (באנגלית: Design pattern) היא פתרון כללי לבעיה שכיחה בעיצוב תוכנה. תבנית עיצוב אינה עיצוב סופי שניתן להעבירו הישר לקוד, אלא תיאור או תבנית לדרך לפתרון בעיה, שעשויה להיות שימושית במצבים רבים.
הממ כבר שחכתי מה התחלתי להגיד, בכל מקרה תראה את הסרטון הזה, אולי תבין קצת יותר מה זה Design pattern ואם אחרי זה יש לך שאלות, שאלנה.
ענה
כמעט נכון. יכול להיות שהדוגמה הבאה תסביר את העניין:
לפני
class X
{
public fnuction Do()
{
$y = new Y();
$y-do();
}
}
{
public fnuction Do()
{
$y = new Y();
$y-do();
}
}
אחרי עם DI:
class X
{
public function __construct(Y $y)
{
$this->y = $y;
}
public function Do()
{
$this->y-do();
}
}
{
public function __construct(Y $y)
{
$this->y = $y;
}
public function Do()
{
$this->y-do();
}
}
במקרה א' במחלקה הראשונה תלויה במחלקה ב'. אם אין לך במערכת את מחלקה ב' - על הפנים.
אם אתה רוצה מחר להחליף את מחלקה Y במחלקה Z או ופעם אחת להפעיל ככה ופעם אחת ככה - אתה לא יכול.
לזה קוראים Inversion Of Control
במקום שהמחלקה שלך תחליט באיזה תלות בדיוק היא משתמשת בפנים - אתה מחליט את זה מחוץ למחלקה.
לממש את זה אפשר בשני דרכים:
Dependency Injection שמובא בדוגמה למעלה, שאתה מחדיר את התלות דרך הקונסטרקטור
או באמצעות Service Locator שנראה ככה:
אחרי עם SL:
class X
{
public function Do()
{
$y = StaticGlobalSystemClass::GetMeAnY();
$y->do();
}
}
{
public function Do()
{
$y = StaticGlobalSystemClass::GetMeAnY();
$y->do();
}
}
את המקרה הזה אני ממש לא אוהב מכל מני סיבות,
מצד אחד היום אתה יכול להכניס לתוך הלוקאטור Y ומחר להכניס Z וזה עובד
אבל מצד שני בעצם לא פתרת את עניין התלויות. במקום שהמחלקה שלך תהיה תלויה במחלקה Y היא עכשיו תלויה במחלקה SL. ולא רק שהחלפת תלות אחת בתלות אחרת, אין לך גם דרך טובה לכפות איכשהו את קיומה של Y בתוך SL.
במקרה של DI המתכת יהיה חייב ליצור מחלקה כלשהי מסוג Y ולהעביר אותה.
במקרה של SL אף אחד גם לא יידע שצריך מחלקה כזאת. הפונקציה תחזיר איזה null ולך תבין למה.
ענה